\documentclass[journal]{IEEEtran}
\usepackage{cite}
\usepackage{url}
\hyphenation{op-tical net-works semi-conduc-tor}

\linespread{1.3}
\begin{document}
\title{Problem Solving and Programming Language Selection}
\author{Anthony~Naddeo,~\IEEEmembership{Student Member,~IEEE,}}%

% The paper headers
\markboth{COS301 Prelim 1, October 18 2011}%
{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.

\maketitle
\begin{abstract}
%\boldmath
Most non-trivial problems have a set of properties that lend themselves well to a set of programming languages. This paper will examine the properties of two hypothetical examples in a generic manner and suggest appropriate languages for them.
\end{abstract}

\begin{IEEEkeywords}
programming language, problem solving, design.
\end{IEEEkeywords}





%------------------------------------------------------------
% Section I: Introduction
%------------------------------------------------------------
\section{Introduction} 

\IEEEPARstart{I}{t} is imortant to realize that programming languages are fundemntally tools to solve problems with, and every problem has a set of properties that would be best solved by a particular type of language. This paper will demonstrate this by examining two hypothetical application specifications that solve differnet problems.

The first application, the Sentence Simplifier, will take a complex sentence and reduce it to a simpler form, where the terms \textit{complex} and \textit{simple} refer to the size of the words and the amount of words in a sentence. The second application will serve as a front-end to a hospital database.

%------------------------------------------------------------
% Section II: Sentence Simplifier
%------------------------------------------------------------
\section{Sentence Simplifier}

\textit{SPECIFICATION: A reading level translator designed to make text easier to read by shortening sentences and substituting words and phrases. For example the system might replace ``utilize'' with ``use'' ``at this point in time'' with ``now.''}

Looking at this specification, we can make some inferences about the properties this application will need.

\begin{itemize}
\item \textbf{Dynamic and flexible}. There is no one-to-one mapping between simple words and phrases they replace, so there can be no brute force, search and replace implementation here (there must be some intelligence to the system).
\item \textbf{Expressive} Natural language can be very ambiguous. Choosing a programming language that can express anything precisely, general or otherwise, is adventageous. 
\end{itemize}

This is not a trivial problem. The most correct programming language to use in this context is not definite either. That being said, this problem would fall under the category of natural language processing, which would intern be considered an artificial intelligence problem. It is in this context that the various Lisp dialects excel. 

Lisp lends itself very well to symbolic programming. This trait combined with its uniform syntax has many implications, one of which being that a program represents a recursive data structure (a tree would be relevant to this problem) where every element or node of that structure also has the ability to posses associations. This means that we can have a natural flow of connections  that can grow dynamically as needed, which is more or less what this problem calls for. 

Each word will be represented as a symbol in a list. Each symbol in Lisp has a built-in \textit{plist} component that acts as an associative array. This can be used to link a particular word with a series of similar words or similar contexts that will determine what words are approriate in a substitution. 

It is possible to represent this reasoning in other functional languages like Python or C++, but the code will not corespond as directly with the reasoning as it will in Lisp, which was designed specifically for symbolic programming. 

The next example has programming languages specifically designed to solve problems for it as well, and Lisp is not one of them.

%------------------------------------------------------------
% Section III: Hospital Database Frontend 
%------------------------------------------------------------
\section{Hospital Database Frontend}

\textit{SPECIFICATION: A front-end data entry system for hospital physicians to enter data into electronic medical records while at the patient bedside.}

Looking at this specification, we can make some inferences about the properties this application will need. 

\begin{itemize}
\item \textbf{Simple and easy to use}. This application is intended for professionals that are trying to solve problems, but cannot be assumed to have any technical computer or programming experience. The front-end should allow users to focus on the task at hand, and not on the application. 
\item \textbf{Database integration}. A database is an appropriate place to store data. Lanuguage candidates should be narrowed down to those that have the ability to interface with a chosen database implementation
\item \textbf{Portable}. Data is entered from a patient's bedside. There is no gaurentee that a patient will not be moved, or a new patient will get a certain room. Each patient's data must be available for input and retrieval from any bedside.
\end{itemize}

The inclusion of simplicity and portability as required characteristics seem to lend well to the use of web tools. Implementing this as a web application would not only make this usable on any computer, but it would also be available on any embedded system with a browser. This means that tablets and smartphones would be instantly compatible as input devices in the hospital.

The hospital would need to supply devices to be used by the bedsides, which would most likely be bulk, embedded devices. These devices can now run any operating system that has browser support, which most likely means that the operating system will go from Windows to a Linux varient and prices will drop as the licensing fees dissapear. 

The inclusion of web technologies implies a handful of langauges, the least of which would be HTML for the layout. In a minimalist design, the only other language needed would be PHP for interacting with a databse from patient webpages. This database would most likely be some flavor of SQL (MySQL seems popular enough).

%------------------------------------------------------------
% Section X: Conclusion
%------------------------------------------------------------
\section{Conclusion}

It is wise for programmers to realize that any given language has strengths as well as shortcomings, even if it is their favorite language. If a problem requires a large amount of users all over the world, on a variety of different operating systems to be able to interface with some centralized application then there is little to be gained by choosing to solve this problem using a compiled, platform dependent language like C as opposed to HTML within a browser, or even Java. Likewise, if you are doing intense number crunching or graph smoothing on a super computer then it would probably be best to go with an efficient, compiled language, optimized for particular hardware rather than a language that might be more expressive or easier to code in. Programming languages are the tools of problem solvers, and should be chosen in relation to a context, not a bias.



%\appendices
%\begin{thebibliography}{1}
%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
%\end{thebibliography}

\end{document}


